The invention relates to control over medical delivery devices and more particularly, to medical delivery systems and methods having safety-enhancing configurations designed to lessen the effects of processor control errors.
Infusion pumps are in widespread use in the medical field. Numerous types of infusion pumps and infusion pump systems are known in the art. Infusion pumps have been designed with the base functions of a delivery rate and a volume-to-be-infused (“VTBI”) (or delivery time and total dose). Over the years as processors have evolved with increased capability, faster speeds, and reduced cost, infusion pumps, as well as many other medical devices that deliver medical treatment to patients, have incorporated these processors and have become more complex with many more features made available. Very complex medication delivery profiles can be programmed into such pumps for the care and treatment of patients. Doctors, nurses, and technicians who are trained to program and use the complex features are often referred to as “super users.” Such super users are able to program such pumps with very complex fluid delivery programs, and in some cases, configure them for specific use in particular wards of hospitals or other healthcare institutions.
Many of these advanced infusion pumps may be used in different pumping modes as the infusion pump may include several embedded programs to enable different operational modes. In the environment of intensive care units, cardiac care units, operating rooms, or trauma centers, it is often necessary to infuse into the patient one to eight different drugs simultaneously. In addition, some of the drugs used in these environments are not directly compatible with each other and therefore need to be infused into the patient at different points of the body. Such multiple infusions at different patient delivery sites require different pumping “channels” or pumping modules. In addition, it is frequently necessary to observe and recall the condition of the patient at certain intervals or to adjust the medication in accordance with the patient's reaction to it. To do so, changes to the pumping program of one channel may need to be made without disturbing drug delivery or device operation of other channels. In addition, in order to be able to recall patient conditions, large amounts of patient data must be stored and access to and manipulation of that data must be made available without disturbing any ongoing pumping processes.
In some cases, a modular programmable patient care system is used that comprises an apparatus for centrally interfacing with a plurality of connected functional devices that provide patient medication infusions and patient monitoring. The number of pumping modules, the complexity of the infusion programs that can be applied for each one, each program of which may differ from the others, and the number and complexity of patient monitors can generate a large amount of data for a central controller to process, and in some cases, can cause data programming and monitoring overloads. Even with single channel devices, the complexity of monitoring and controlling the device has created a time management issue when the user interface is added to the activities being controlled and responded to by the processor. Adding multiple channels just increases the probability of time management issues.
Such systems containing multiple infusion pumping devices are known in the medical field and are a natural response to the need for multiple pumps on a single patient. For example, U.S. Pat. No. 4,756,706 to Kerns et al. discloses a centrally-managed infusion pump system in which pump and monitoring modules are attached to a central management unit (CMU) or central controller. The central management unit controls the internal setup and programming of each of the attached pump modules, and receives and displays information from them.
U.S. Pat. No. 4,898,578 to Rubalcaba, Jr. also discloses a medication infusion system that includes a plurality of infusion pump modules that may selectively be attached to a central management unit or central controller (CMU) so as to provide for centralized control. In particular, the CMU obtains infusion parameters from the user and then performs calculations with the parameters to establish the desired infusion rate at a designated attached pump module. Once this rate is determined, the central management unit controls the infusion accordingly.
Turning now to FIG. 1, there is shown an existing medication delivery system 20 comprising a central management unit 22 (CMU), three infusion pumps 24, 26, and 28, and an oximeter 30, all of which are connected with and controlled by the CMU. All of the infusion pumps and the oximeter are connected with the same patient 32 in this example. All the foregoing devices 22, 24, 26, 28, and 30 are mounted to a floor stand 34 having a stable base 36. Also mounted to the floor stand at its top is a medication hanger 38 from which three medication containers are hung 40, 42, and 44. The right-most container 40 is connected with the top pump 24 and the patient 32 through a fluid line 46, with the pump controllably delivering the fluid of the container 40 to a first delivery site 47 at the patient. The middle container 42 is connected with the center pump 26 and the patient 32 at a different location, or delivery site 49, than the top pump through a fluid line 48, with the pump controllably delivering the fluid of the container to the patient. The left-most container is connected with the bottom pump 28 and the patient 32 through a fluid line 50 with the pump controllably delivering the fluid of the container to yet another delivery site 51 on the patient. The oximeter 30 receives oximetry data from a sensor (not shown), located at the patient at a location 53, selected so at to sense the necessary patient physiology, through a data line 52 for processing.
The CMU of FIG. 1 includes a user interface 58 comprising a display 60 and a keypad 62. The CMU receives programming input through its interface 58 and provides real-time programming control over each of the pumps or channels 24, 26, and 28. The CMU provides instructions to each of the pumps in real time to which they are responsive, it monitors the functional operation of each pump, and it monitors the operating timers of each pump and its respective processor. The CMU stores a drug library that is used both as a safety feature and a data base. The CMU monitors the delivery of each pump and updates instructions in real time to each pump according to programming of the CMU and possibly in accordance with oximeter data. The CMU also responds to user data entry to update instructions to one or more of the pumps. The pumps are responsive in real time to the updated instructions; i.e., they are under the direct control of the CMU. The CMU may or may not be connected with a remote processor, such as a pharmacy server, or an administration server central to a healthcare facility.
In the centralized control systems discussed above, there are several disadvantages. For example, in these systems the central management unit must be aware of and must control much of the functionality of the attached pump units. This can result in a large data processing load for the CMU. Some systems include a single complex central management unit (CMU) that must be used to control and program multiple infusion pumps. Complex central management units having a high data processing load are undesirable in clinical situations due to the possibility that a data overload may occur in which the processor is unable to timely process all data and output instructions. In such a situation, the CMU typically shuts down and consequently, all pump modules are shut down since they are under the direct control of the CMU. Shutdowns of the CMU and its pump modules can occur unpredictably with the result that the patient does not receive the medication at the desired time unless the system can be reset and restarted immediately or a replacement system can be located and programmed immediately. The same shutdown can happen in a single-channel pump where the processor becomes overwhelmed by complex programming and data processing requests.
Medication errors, that is errors that occur in the ordering, dispensing, and administration of medications, regardless of whether those errors cause injury or not, are a significant consideration in the delivery of healthcare in the institutional setting. The Sep. 9, 2002 issue of Archives of Internal Medicine reported a study indicating that nearly one in every five doses of medicine given to patients in the typical hospital is a medication error (“Medication Errors Observed in Thirty-Six Health Care Facilities”). This study confirms the findings from earlier reports, including the 1999 Institute of Medicine Report, which revealed that more than 50,000 deaths in the United States annually are the result of medication errors. Medication errors are the eighth leading cause of death in the United States. Additionally, adverse drug events (“ADE”) defined as injuries involving a drug that require medical intervention, which are a subset of medication errors, represent some of the most serious medication errors, and are responsible for a number of patient injuries and death.
Healthcare facilities continually search for ways to reduce the occurrence and severity of medication errors. Various systems and methods have been considered and developed at present to reduce the frequency of occurrence and severity of preventable adverse drug events (“PADE”) and other medication errors.
Manufacturers have tried using various techniques to avoid infusion errors, one of which includes the use of hand-held personal digital assistants (“PDA”) that are designed to provide drug administration scheduling, drug administration verification, and the electronic documentation of drug administration. These devices are predominantly used to verify the administration of oral, intramuscular (“IM”), subcutaneous, and topical drugs and have limited capability in verifying the administration of intravenous (“IV”) drugs. PDAs have been found to be useful for scheduling and perhaps monitoring, but can do very little or nothing about data overload and shutdown of an infusion pump system.
Healthcare facilities continuously strive to provide quality patient care and many steps have been taken to lessen the chances of such errors occurring. The possibility of medical errors, such as where the wrong patient receives the wrong drug at the wrong time, in the wrong dosage, or even where the wrong surgery is performed, are a significant concern for all healthcare facilities. Various solutions to these problems have been proposed, such as systems that use bar codes or RFID tags to identify patients and medications, or systems allowing the beside entry of patient data. While these systems also have advanced the art significantly, infusion data processing and programming errors continue to be a problem. For example, even where the medication order includes the correct infusion parameters and those parameters are correctly entered into an infusion pump, a data overload of the pump's processor or a remote centralized processor may cause the pump to stop administering the medication to the patient, thus causing a delivery error to the patient.
As briefly mentioned above, very complex pumping programs can be generated in the care and treatment of patients. The ability to control automatically a pump to provide a complex medical delivery regimen or pattern can have a significant benefit for a patient. A medication delivery pattern can be designed to optimize delivery of a particular medication that takes into account factors of the particular situation. Costs are lowered since the attention of nurses is not required each time a delivery parameter of the pump must be changed—it is done automatically. Although conventional drug infusion controllers have greatly improved the efficiency and ease with which medications are delivered to a patient, complex pumping programs, and the data produced from them, can reach the limits of certain processors. Data overloads are possible and their occurrence is not predictable. In some areas of medication delivery, even higher levels of data and instruction processing are necessary. The processor is “highly” taxed and when multiple requests are made of the device, changing delivery parameters occur, complex algorithms are running, single fault failure timing is in place, etc., devices on the market are shutting down without alarm conditions in some instances. The issue is the defined frequency of monitoring and control interface with the pump while also needing to recognize and respond to the user interface.
For example, certain pharmacokinetic models can require very complex infusion programs. U.S. Pat. No. 5,010,473 to Jacobs discloses a model-based open-loop process for controlling the concentration of a drug delivered intravenously to a patient as a function of the rate of infusion. A three-compartment pharmacokinetic (PK) model is used to determine the plasma drug concentration. Such PK systems are attractive for certain therapy, but require a large amount of programming, data manipulation, and control. Based upon the linear relationship between data pairs comprising a rate of infusion and a corresponding plasma drug concentration, an interpolated rate is determined by a microprocessor as a function of the specified plasma drug concentration. The actual infusion rate of the drug during successive time intervals is repetitively used to compute the plasma drug concentration at the end of each time interval. For each iteration, state variables from the previous computation are applied to determine the next interpolated infusion rate. Open-loop medication delivery control methods can achieve the specified plasma drug concentration, but a relatively complex medication delivery program is incorporated.
It will be apparent that controlling the administration of a plurality of drugs through a multi-channel drug infusion system using a PK model to predict the drug concentration and control the rate of infusion would require significant programming tasks over the prior art control of a single channel. If desired, a different PK model could then be selectively applied to control the delivery of each different drug through each channel of a multi-channel drug delivery system, or the same model could be used for the control of each channel of the system.
At times, a physician may find it necessary to alter briefly the parameters of a drug therapy. If the drug administration is being controlled by a PK model, the physician may want to switch to a manual mode for a period of time, for example, to administer a bolus dose. It should thereafter be possible to switch back to the PK model controlled mode. Accordingly, it is important that the control for a pump that is used to administer drugs in accordance with a PK model be able to track the history of the drug administered and take into consideration changes that occur while the PK model controlled mode is interrupted by a manual controlled mode, when the PK model control mode resumes. Since the history of the blood plasma concentration must be retained to achieve this goal, the infusion system control should be able to display both historical and predicted blood plasma and compartment effect drug concentrations levels to medical personnel for each drug administered, during either model controlled or manual controlled modes of operation. The model should continue to track and display these parameters, even after the drug infusion has stopped, so long as the patient's case is active. If all the above is performed by an infusion pump, or by a system of pumps with a central controller, significant data processing loads can occur for the processor or processors involved. Should such data loads exceed the processor's capability, a shut-down may occur and the therapy could be delayed.
It has been recognized that infusion pump designs currently on the market present potential safety issues. This may best be demonstrated by the fact that the U.S. Food and Drug Administration (“FDA”) issued a proposed Infusion Pump Improvement Initiative on Apr. 22, 2010. Their justification for the initiative is that the number of recalls and potentially understated number of safety events involving infusion pumps are too high.
Observations:
The following observations are made after a review of FDA Medical Device Reports (“MDRs”), details provided with infusion pump recalls, and assessment of human factors known to exist in health care facilities.                During pump operation, software, hardware, and the user interface make major contributions to reported causes of pump recalls.        A. The intravenous (IV) infusion pump hardware/software interface uses a master/slave model where the master process controller, or “master processor,” is the master for multiple channels. The master/slave relationship mandates that the pump channel operate only when the master control module or processor is functioning properly. This master/slave model can result in conflicts between the master processor's need to perform specific system checks and the user's demand for the master processor to process instructions being provided by the user. The processor as the master requires that the pump performance be interrupted if a processor or control module failure occurs.        B. To clarify the above problem through a comparison to another high data load system, video game programmers are faced with the same problem in that as the console game program begins to utilize too high a percentage of the processor's capacity, the “super user” begins to see slight delays in the video updates (for example, characters begin to freeze in place on the screen). The same is true with IV infusion pumps. The exception is that with the IV pump, the super user sees an error code or a potential programming error. The significant number of recalls associated with this design approach has been used as part of the FDA Infusion Pump Improvement Initiative        Complexities of pump programming are not supported with the user interface screens provided with the feature-enhanced infusion pumps currently on the market.        Numerical keypads have a similar data entry error rate regardless of the style of keypad used. This added with the human factor of confirmation bias (humans tend to fail to check closely when asked to confirm) results in some level of over- or under-infusion of the solution (drug).        The advanced infusion pumps provide the users with the ability to program the pumps to address many different therapeutic procedures. However, the same feature enhancements require the user to program the pump while advancing through a series of screens. Each screen may use the same key as previously used for a different purpose. The potential errors associated with multiple functions for the same key potentially increase the error rates experienced as practitioners move from one patient population to another.        Infusion pumps are designed to address all of the needs in the healthcare facility; i.e., they have the ability to pump a wide range of volumes. This increases the pump's ability to deliver significantly more fluids than reasonably logical to neonatal patients and also allows deliveries so small that the delivery rates are not clinically significant for large adult patients.        The infusion pumps do not support easy readability during operation. This is especially true when multiple channels are operating and an error condition is detected. Alarms sound and delivery stops or is affected as a result of the error conditions. This condition is further complicated when the practitioner attempts to clear the error condition at the CMU and incorrectly takes action on channels not affected by the error condition.        No infusion pump currently on the market known to the inventors was designed to address the specific needs of anesthesia.        No infusion pump currently on the market addresses the specific needs of the neonatal intensive care patient population. Specifically, the drug dilution of many drugs being delivered at the same time may actually require the neonatal patient to receive more total fluids than is therapeutically beneficial to the patient.        
Hence those skilled in the art have recognized a need for safer medication delivery devices. A need has also been recognized for a medical delivery device that is not susceptible to terminating delivery of a medication in the event that a remote processor that is controlling delivery ceases functioning properly. An additional need has been recognized for a medical device that is capable of receiving and operating under a complex medication delivery program. Another need has been recognized for safer data input devices and methods so that fewer mistakes are made when inputting data related to medication delivery. The invention fulfills these needs and others.